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ABSTRACT 

This paper presents the ideas underlying a computer program that takes as input a schematic of a mechanical 
or hydraulic power transmission system, plus specifications and a utility function, and returns catalog 
numbers from predefined catalogs for the optimal selection of components implementing the design. Unlike 
programs for designing single components or systems, this program provides the designer with a high level 
“language” in which to compose new designs. It then performs some of the detailed design process for him. 

The process of “compilation”, or transformation from a high to a low level description, is based on 
a formalization of quantitative inferences about hierarchically organized sets of artifacts and operating 
conditions. This allows design compilation without the exhaustive enumeration of alternatives. The paper 
introduces the formalism, illustrating its use with examples. It then outlines some differences from previous 
work, and summarizes early tests and conclusions. 


This report describes work done at the Artificial Intelligence Laboratory of the Massachusetts In¬ 
stitute of Technology. Funding for the work was provided in part by the Industrial Technology 
Institute of Ann Arbor, Michigan, and in part by the Office of Naval Research under University 
Research Initiative contract N00014-86-K-0685. 



1 Introduction 


... in practice, failure is still far less frequently the result of bad working principles than 
of poor detail design. Pahl and Beiiz[l] 

In this paper we introduce the theory underlying a computer program that selects standard 
components from catalogs in order to implement a wide variety of mechanical designs. The user of 
the program forms a schematic by combining such elements as those in Fig. 1. Given the schematic, 
specifications, and a utility function, the program returns the optimal catalog numbers. 

We can view the schematics and the specifications as a description in a “high level (source) 
language”, and the catalog numbers as a description in a “low-level (target) language”. Then, by 
analogy with computer language compilers, we can call our program a “mechanical design compiler”. 
Like computer language compilers, such programs should improve designer productivity, prevent 
errors, and allow the exploration of more alternatives in greater depth. 

1.1 Observations on Component Selection 

Suppose that we wanted to design a power train for an ice-cream stirrer (Figure 2). We will 
call this the Toscanini’s problem, after a local eatery. Given a range of acceptable stirring speeds, 
the torques required, and a catalog, we might use the transmission input-output equations RPM{ = 
(ratio)(RPM 0 ) and torque 0 = (ratio)(torque i ) to systematically eliminate those transmissions unable 
to provide the required speed with the available motors. Then we might eliminate those motors 
unable to provide the required torque through any of the remaining transmissions. 

We have several observations to make. First, note that in this example we think about sets 
of artifacts (e.g. all Dayton 3-phase motors), rather than particular artifacts (the motor that 
fell off the loading dock yesterday). Because of manufacturing variation, even a single catalog 
number designates a set of different physical artifacts, which may or may not be interchangeable in 



Figure 1: Schematic elements 
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a particular design. We must also consider sets of operating conditions; for example, the ice cream 
maker may be nearly empty, or full of cold Double Dutch Chocolate. We cannot always assume that 
the maximum load is the only one that matters—some electric motors over-heat unless operated at 
nearly full load. 

Second, torque is a quantitative property, normally expressed in terms of real numbers. Our 
reasoning about torque is therefore also quantitative. However, while the torque at a particular 
operating condition is normally represented by a real number, the torques required by the stirrer 
under all ice-cream viscosities and fill levels correspond to an interval of real numbers (say those 
from 10 to 40 newton-meters.) 

Third, the artifact sets are organized, for example by horsepower and motor speed. We can 
eliminate large sets simultaneously (e.g. all the motors of less than 1 horsepower). 

Finally, the only mathematical expressions used in the example were algebraic equations. Most 
designers would attack the problem by substituting single values (say for the largest output torque) 
into the equations, then comparing the results with other single values from catalogs. If asked 
to justify using calculations on single values to draw conclusions about sets, they would provide 
intuitive arguments, in English and specific to the particular problem being considered. 

We might write these intuitions into an “expert system”, and that program might work well in 
a sufficiently narrow domain. But a compiler should give correct results on every design which can 
be composed from the schematic elements. It therefore needs a general and precise theory, which 
can be closely examined and confidently applied to diverse design problems. 

1.2 Preview 

This paper introduces a theory for quantitative inference about sets of artifacts and operating 
conditions. The theory provides the basis for a mechanical design compiler which operates by 
eliminating unsatisfactory alternatives from catalog sets of artifacts. 

We will begin with a brief overview of the compiler. We then introduce some operations on real 
number intervals. From intervals, we build up a language of “labeled-intervals”, or “specifications”. 
Then, we illustrate the use of formal operations on this language to perform quantitative inferences 
in the solution of the Toscanini’s problem. 

2 A design compiler 

A user of our compiler creates a design schematic by pointing in sequence at displayed icons. 
Each icon represents a computational “object”, which normally includes a list of catalog numbers. 
Thus, it also represents the set of real artifacts purchasable by ordering from the catalog. Associated 
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with each catalog number are specifications in the labeled interval language. Other specifications 
automatically abstracted from these, along with equations built into the schematic object, describe 
the whole set of artifacts represented by the icon. 

The schematic assembly process establishes an identity between corresponding variables for con¬ 
nected components. For example, in the Toscanini’s problem the output torque of the transmission 
is identified with the input torque to the stirrer. 

Having assembled a schematic, the user supplies specifications in the labeled interval language 
for the most convenient objects, usually loads. The objects pass each other these specifications, the 
specifications abstracted from the artifact sets, and new specifications derived from these by using 
equations. The objects eliminate from consideration incompatible artifacts (by deleting numbers 
or groups of numbers from the catalog listing), and abstract new descriptions for the resulting 
subsets. In the Toscanini’s problem, the user might specify the range of torques required at the 
stirrer input shaft. This information, propagated through equations in the the transmission object, 
would eliminate those motors unable to supply enough torque to drive the load through any of the 
transmissions under consideration. 

Since the information reaching the motor object is about all the possible combinations of trans¬ 
mission and load, the compiler does not explicitly enumerate the alternative combinations of motor 
and transmission. This approach may be contrasted with one in which alternatives are generated, 
evaluated, and discarded or modified. If we think of the design process as searching a space of 
artifacts, our approach works by eliminating volumes of the space, while the other evaluates designs 
at points in the space. At any time during our program’s operation, the schematic represents the 
volume of the artifact space which has not been eliminated. 

This approach has several advantages. 

• Manufacturing tolerances and operating condition variations are represented explicitly. 

• The program need not examine each alternative individually. 

• Elimination inferences, unlike choice inferences, can be confidently made from partial infor¬ 
mation. For example, our program does not yet contain a representation of geometry, but 
it can still safely eliminate motors providing insufficient torque. It could not safely choose a 
motor—it might not be suitable geometrically. 

• The inference system has been designed to produce only statements which are true of each 
of the objects being considered at the present stage of compilation. The sets of artifacts 
considered at later stages will be subsets of this set, so the statement will still be true of each 
artifact. Therefore, statements never need to be withdrawn. 

• The meaning of design representations is often left intuitive; designs are sometimes said to 
stand for an “archetype”, or a “partially defined object”. In contrast, at each stage of the 
compilation process our representation stands for a well-defined set of physical objects. We 
can therefore evaluate operations by using physical reasoning about the objects represented 
before and after a formal operation. 

This set-based approach, however, has one significant disadvantage: conventional, single-valued 
or even “constraint propagating” systems of mathematical inference are inadequate to deal explicitly 
with sets of artifacts and operating conditions. We now begin building appropriate inference tools 
based on relationships between variables and intervals of real number values. 
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3 Some Operations on Intervals 


We need to work with sets of values, for example the torque required to drive an ice cream stirrer 
under all load conditions. We might write 0 < torque < 10 (in our favorite units), or torque 6 [0 10] 
but will instead write ( torque 0 10); for now, the reader can assume these statements mean the same 
thing. 

Using this notation, we will present eight operations on intervals. Because we are trying to 
convey a general understanding we will present the operations using examples, and claim without 
proof that under appropriate circumstances the operations are both well defined and computable. 
For more detail, see [2]. 

The first five operations used by our design compiler are straightforward, and are illustrated in 
the following examples. 

• Intersection: D((x 1 4), ( x 2 6)) —>(x 2 4). 

• Not-intersection:l7i((x 1 4), {x 2 6)) —► False. 

• Filled-union: U((x 1 4),(x 8 10)) —>(x 1 10). 

• Subset: C ({x 10 12), (x 10 14)) — >True. 

• Not-subset: g ((x 10 12), (x 10 14)) —>False. 


We will call the sixth operation Range. Range takes an implicit equation in three variables and 
a pair of intervals in two of the variables, and returns the compatible interval in the third variable. 
More precisely, suppose that g(x, y, z) = 0 is the implicit equation, and X and Y are intervals in 
x and y respectively. Then Range^, X, Y) —► Z, where Z is the minimal interval such that for 
every assignment ofiGX and y e Y, there is an assignment of z £ Z which satisfies g. 

Let us do an example. Suppose that in the Toscanini’s Problem, we had available transmission 
ratios only from 2 to 4, and we knew that output torques above 8 would damage the stirrer. Figure 3 
represents the transmission equation, t, — y. = 0, by showing lines of constant output torque. 
From the figure we see that regardless of our choice of transmissions, any motor providing input 
torque above 4 will induce output torque above 8. We might reasonably conclude that regardless of 
our choice of transmission we should not use any motor producing running torques above 4. 

The Range operation produces the appropriate interval: 

Range(U - = o, (t 0 0 8), (ratio 2 4))— ►(*,- 0 4). 

The Range operation is equivalent to what is usually called the constraint propagation of inequal¬ 
ities, and has been well explored[3]. However, it is not the only operation of interest. Suppose that 
instead of saying that the stirrer will be damaged by torques above 8, we say that torques ranging 
from 0 to 8 may be required to drive it. We should conclude that we need motors able to provide 
torques ranging ranging at least from 0 to 2; see Figure 4. We will call the operation producing this 
interval Domain; it can be defined as an inverse of Range. For example, 

Domain^ - = o, (t 0 0 8), (ratio 2 4))—►(*,• 0 2) 

J Utlv 

precisely because 


Range (U - 


to 

ratio 


= 0, (t, 0 2), (ratio 2 4)) 


(to 0 8 ). 


Finally, we define the eighth operation, Sufficient-Points, as another sort of inverse to 
Range. Suppose in the Toscanini’s problem we knew that we had available only motor torques 
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Figure 3: An illustration of the Range operation 



Figure 4: An illustration of the Domain operation 


up to 2, and we needed stirrer torques up to 8. Looking at Figure 5 we would conclude that any 
transmission ratio of 4 or above would do. That is, 

SufPt(1,- -= 0, (t 0 0 8), (ti 0 2)) —>(ratio 4 oo) 

I U l Its 

because for all ratios in [4 oo], the Range of the ratio and the input torque includes the output 
torque. For example, a ratio of 5 would give the output torque interval 0 to 10, which includes the 
desired interval, 0 to 8. 

RANGE(t t - -= 0, (t{ 0 2), (ratio 5 5)) — >(t{ 0 10). 
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Figure 5: An illustration of the Sufficient-Points operation 


All of the operations presented are sometimes useful in design, but when should we use each one? 
In these examples we used our experience as designers to decide which operation would produce the 
desired interval. In a formal system, we need to build the information guiding those decisions into 
the specifications themselves. We will call these augmented interval statements labeled intervals. 

4 The labeled interval specification language 

We will return to the examples of the previous section, but first introduce the language of labeled 
intervals using an even simpler design problem—selecting one of a set of motors to be connected 
directly to a load (Figure 6). 


motors 


load 


Figure 6: A very simple power train 


4.1 Limits and operating regions 

Suppose that we know that each of some set of motors can produce torques throughout the 
interval 0 to 20, but that damage may result to the load if the torque goes above 10. We want to 
eliminate these motors from consideration. Given only the intervals ((t 0 20), (t 0 10)) a program 
would not have enough information to specify what operation to use. For example, if the larger 
interval applied to the load and the smaller to the motors, we would not eliminate the motors. We 
can attach the information required using the following labels. 

The Limits label, symbolized by [ ] , indicates that values of the variable will or must be drawn 

. only 

only from the interval. Thus, {[ ] t 0 10} means that the torque must not reverse or go above 10. 
Similarly, the tolerance on a bearing inner diameter can be expressed as ([ ] d ,• 2.99 3.01). 
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The Operating-Region label, symbolized by ev " y ; indicates that the variable will or must 
assume every value in the interval; f o 20) indicates that the motor torque can at least range 
from 0 to 20 (and perhaps beyond.) 

We will later define a rule which eliminates these motors because, for the variable t, the operating- 
region interval is not a subset of the limit interval. 

4.2 Required, Assured, and No-stronger labels 

Suppose that in our motor-load example we want the load speed to be regulated to between 1750 
and 1800 rpm. We introduce a Required (R) interval label, meaning that the statement must be 

true for proper function. For the load, we can write (r n RPMl 750 1800). 

Suppose further that some catalog number designates a set of high-slip motors, capable of reg¬ 
ulating the speed only well enough to keep it between 1725 and 1800. We introduce the No- 

stronger-possible (N) label, and write for the high slip motors (N ["*] RPM1725 1800). By this 
we mean that we cannot specify any subset of these motors which guarantees stronger limits. (Be¬ 
cause of manufacturing variation, some of them probably do guarantee better speed regulation, but 
we cannot, within the framework given, select these.) We will define a rule which eliminates these 
motors because the No-stronger-possible limit interval for RPMis not a subset of the Required limit 
interval. 

The final label in this class is Assured (A), indicating that we are sure a particular statement 
will be true for all the artifacts represented (under appropriate conditions). Thus for our high slip 

only 

motors, we have also (A [ ] RPMl 725 1800). 

We have illustrated the Assured, Required, and No-stronger-possible labels only in conjunction 

with the Limit ([ ] ) label, but they can be defined comparably in conjunction with the Operating- 
Range C~ y ) label. 

Labeled interval descriptions are models of artifact sets, and we can choose the level of abstraction 
of the model. For example, there is a torque curve for each motor type, which would allow more 
accurate prediction of the speed regulation based on the possible torques. If we chose to include 
the torque curve in our describing equations, we would apply labeled interval specifications to the 
equation’s coefficients. 

In addition to the labels defined above, we designate each quantity as either a state variable 
or a parameter. Parameters, such as gear ratio, are fixed at manufacture, while state variables 
like torque may vary during operation. 

Each labeled interval pertains only to a specified set of operating conditions such as start-up or 
normal operating conditions. We will assume “normal operating conditions” throughout this paper. 

5 Operations on Labeled Intervals 

The key activities of our compiler can be specified by three groups of formal operations on 
labeled intervals: elimination, abstraction, and specification propagation. 

5.1 Elimination 

These operations eliminate artifact sets whose labeled interval specifications conflict with the 
specifications imposed by the user or by other parts of the design. 

We represent these operations using patterns. Suppose that for our motor-load power train we 

have the same speed regulation requirement as above: (R ["'! RPM1750 1800). We want to elim¬ 
inate motors with weaker speed regulation, say (N ["^ RPMl725 1800). These two specifications 
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match the pattern 


only only 

{N [ ] X x u ) ^ (R [ ] X xt x u ) —►eliminate, 

with X taken to be the RPM and X\ and x u the lower and upper bounds of the corresponding 
intervals. 

Since the No-stronger-possible specification is not a subset of the Required specification, the 
program removes the relevant catalog numbers from the associated list. 


only 


«R A) ''A"*...) g((R A) n»...> 

«R A) f 1 ] x ...) I 7 I((R A) rv..> 


<«["'!*...>£ «r a) ru..> 

((R A) ”i , » * ...) 2 (N x..: 


Table 1: Elimination patterns 

All our elimination patterns are shown in Table 1 (with the arrow and the word “eliminate” 
omitted for brevity). When the list “(R A)” appears in a pattern, it can be matched against either 
a Required or an Assured statement. 

5.2 Abstraction 

In the Toscanini’s problem, we want to evaluate motor alternatives with respect to the set of 
all transmissions under consideration. Therefore, we need a set of specifications which describe 
all the transmissions. The program abstracts these specifications from the previously encoded 
descriptions of the individual “catalog number” subsets. 

The program uses either the intersection or the filled-union operation to combine the intervals 
associated with a given variable and pair of labels in each subset. For assured limits it uses the filled- 

union operation, so for example it combines (A [ ] RPM115Q 1200) and (A [ ] RPM1750 1800) 

only 

to form (A [ ] RPM1150 1800). There are six types of labeled interval defined by combining the 
two label sets (Assured, Required, No-stronger-possible) and (Limit, Operating-Region). Table 2 
shows the operation appropriate for combining each type of labeled interval. 


interval type 

operation 

(A ) 

n 

only . 

(A[]) 

U 

(R “Z* ) 

n 

(R- [ ] > 

u 

(N ev ~ y ) 

u 

only . 

<N[ ]> 

_G_ 


Table 2: Abstraction operations 


5.3 Propagating Labeled Intervals Using Equations 

We turn now to a more complex question: how can we propagate labeled intervals through 
equations, so that, for example, the torque requirements for the ice cream stirrers can be converted 
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into torque requirements for the motors? We introduce two operations on labeled intervals and 
equations. 

The first is represented by the following pattern: 

only only 

((R A) [ ] tii) & {(R A) [ ] v 2 ) & g(vi,v 2 ,v 3 ) = 0 

only 

—>((RubA) [ ] i > 3 Range). 

The labeled interval patterns to the left of the arrow are matched with potential inputs to 
the operation, while the pattern to the right of the arrow defines the form of the output. The 
“g(vi, v- 2 , v 3 ) = 0” matches equations linking the two input variables and the output variable. The 
“(R A)” in the input patterns again indicate that the operation is appropriate for either Required 
or Assured statements. The “(RubA)” in the output indicates that the output will be Required 
unless both inputs are Assured, in which case it will be Assured. Finally, the “Range” in the 
output pattern indicates that the numeric values are to be found by applying the Range operation 
to the input values. 

Suppose again that in the Toscanini’s Problem, we have available transmission ratios only from 
2 to 4, and we know that torques above 10 would damage the stirrer. The specifications match our 
pattern: 


, only , , v only 

(R [ ] U 0 10) ~ <(R A) [ ] tq) 

only only 

(A [ ] ratio2 4) ~ ((R A) [ ] v 2 ) 

= 0 ~ 9(vi,v 2 ,v 3 ) = 0. 

only 

This justifies applying the Range operation to form (R [ ] <,■ 0 5). The elimination operations 
will use this new specification to eliminate any motor producing torques above 5. 

The second operation is represented by the pattern 

((R A) ev " y si) & ((R A) [ \ p 2 ) k. g{si,p 2 ,s 3 ) = 0 

—*• ((RubA) ev ~ y s 3 Domain). 

Reading the pattern, we see that the first input must be an operating-region interval and the 
second a limit. The first input and the output variables must be state variables, while the second 
input variable must be a parameter. The output interval is formed by applying the Domain oper¬ 
ation to the input intervals. The (RubA) rule is applied again. The idea is that if we need a state 
variable to take on every value in a certain operating-region, and we have some limited choices of 

parameters in the equation, then the other state variable must take on values over a sufficiently large 

interval to satisfy the equation with at least one of the parameters available. If we need torques up 
to 8 to drive the stirrer, we can match the specifications with the pattern: 

(R ev ~ y t 0 0 8) ~ ((RA)'^ Sl ) 

, only % _ „ only 

(A [ ] ratio2 4) ~ ((R A) [ ] p) 

7*1"-** = 0 ~ ff(»l.«2.«3) = 0. 

We therefore apply the Domain operation to form (R ev SI y ti 0 2); the motors are required to 
supply torques throughout the operating-region from 0 to 2. Note that this specification does not 
imply that the input torque t,- can never be greater than 2, but rather that all motors considered 
must be able to supply torques of at least 2. If at some point the transmissions of ratio 4 are 
eliminated from consideration, a new labeled interval requiring higher ti will be generated. 

Table 3 shows all the propagation operations. Symbols representing the associated equations are 
omitted for brevity. The list “(p s)” may be matched against either a parameter or a state variable. 
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The 1 and j operations, given intervals in a variable, extend the interval upward to infinity or 
downward to zero respectively. The sorne label indicates that the variable must take on at least one 
value in the interval; see [2] for details. 


(A 8l ) k (A ^ S2 ) -—(A s 3 Range) 

(R ev Z y Sl ) k {R S2 ) — *-(R ev <l ry s 3 Range) 

(N ev Z y Sl )k {N ev Z y s 2 ) —►(N et, <l ry s 3 Range) 

only only only 

((R A) [ ] (pi si)) k ((R A) [ ] (p 2 s 2 )) — -((R ubA) [ ] (p 3 s 3 ) Range) 

<(R A) n S v s x ) k <(R A) ["I ( P 2 s 2 )) — *-((R ubA) ev Z y s 3 Domain) 

<(R A) e ~ ry Sl ) k ((R A) n * 2 ) — *-(R [ nl 1 Pa SufPt) 

(N “S” si) k (N n Pz) —><N ev ~ ry s 3 Domain) 

(N ev Z y si) & {(A R) ["'] (P 2 * 2 )) — (N s 3 Range) 

(A ev ~ y si) k (N ["*] p 2 ) —>-(N A s 3 Range) 

(R "S* si) k (N s 2 ) — +<R ["'] Pa SufPt) 

(R ev Z y si) & (N s 2 ) —(R e ^ ry s 3 Domain) 

only only only 

(N [ ] (pi si)) k ((A R) [ ] (p 2 s 2 )) —>(N [ ] (p 3 s 3 ) Domain) 

. on/y on/y only 

(R [ ] si) k (N [ ] p 2 ) — >{R [ ] s 3 Domain) 

{R si) k (N ["'] p @ ) — >-(R s 3 Range) 

<(R A) e ~ ry Sl) k {(R A) rl (P 2 s 2 )) —*-((R UbA) ,ome s 3 SufPt) 

((R A) e « ry si) k (N e ~ ry s 2 ) — >{(R ubA) ,0,ne s 3 SufPt) 

{(R A) ev Z y si) k ((R A) s< ” ne s 2 ) 

— *-((R ubA) et, A ry s 3 (Domain(si,s 2 ) nDoMAlN(T (si),s 2 )) ) 

U 

(DOMAIN(si,S 2 ) nDOMAINQ. (si),S 2 )) 

((R A) e ^ ry Sl) k {(R A) some s 2 ) 

— i-((R ubA) JO,ne s 3 (SufPt(si,s 2 ) DSufPt(T (si),s 2 )) ) 

U 

(SufPt(si,s 2 ) nSuFPT(| (si),s 2 )) 

((R A) ([”'] s ° me ) (Pi s0) k {(R A) some s 2 ) — ((R ubA) 5 ° me s 3 Range) 
((R A) (["'1 so,ne ) (pi Si)) k <(R A) * ome s 2 ) — »((R ubA) ["'] Ps Range) 
{(R A) ,ome si) k (N PH P 2 ) — *-((R ubA) so ™ e s 3 Domain) _ 

Table 3: Inference patterns using equations. 


5.4 Review of the literature 

We have been influenced by a number of general ideas. De Kleer[4] argued that much of our 
knowledge about the physical world is left implicit by classical mechanics. “Constraint propagation” 
can be traced to Sutherland [5]. “Silicon compilers” [6] suggested that design operations could be 
regarded as transformations of formal descriptive languages. Chapman[7] argued that “partially 
completed plans” represent sets of possible plans; we have directly adapted this idea to physical 
artifacts. 
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Work using artificial intelligence methods to study mechanical design can be arranged along a 
spectrum of increasing abstraction from human design activity. At the most abstract point of this 
spectrum, Fitzhorn and his students are using Turing machine models to establish fundamental 
conclusions about the design process [8], while Yoshikawa[9] views design descriptions as topologies 
on a space similar to our artifact space. Conversely, at the “human model” end, Waldron and 
Waldron[10], and Ullman and Dietterich[ll] study human designers using the methods of the social 
sciences. 

Toward the “human model” end, Shin-Orr[12], Brown[13], and Mittal, Morjaria, and Dym[14], 
have developed expert systems” to design multiple-spindle gear drives, air-cylinders, and paper- 
paths respectively. These programs use hierarchical control, trial solutions and back-tracking. They 
apply heuristics obtained by studying experts, and appear to give nearly expert performance in 
narrowly defined domains. 

Near the center of the spectrum we might place work focusing on a single strategy. The Dominic 
series of programs by Dixon and his students[15], implement a modified “hill-climbing” procedure, 
searching from point to point in the design space. Problems like the Toscanini’s are coded by the 
programmer, rather than assembled from schematics, but much of the system is independent of the 
particular problem. Also by Dixon and his students are a series of works on “design by features” [16], 
Features are geometrically oriented entities (corners, bosses). It appears that compatibility between 
mating features must be maintained by “hard code”, and that in general the systems warn if con¬ 
straints are violated, rather than using constraints to set values. Papalambros[17], and Rinderle[18] 
are working on a variety of design support issues and tools, spread across the spectrum. 

Our work belongs with a cluster slightly further toward the more abstract end of the spectrum. 
Ulrich and Seering [19] use “generate, test, and debug” schemes to transform differential equations 
into schematics, and schematics into more specific pictorial representations. The program does not 
use quantitative methods for elimination or optimization, instead presenting the human designer 
with a variety of alternatives. Wood and Antonsson[20, 21] have been exploring the use of fuzzy set 
theory and fuzzy arithmetic in analyzing designs. 

A version of the idea that designs represent sets of artifacts appeared in Requicha’s[22] theoretical 
study of geometric tolerancing. 

Agogino and Cagan[23] extend formal optimization methods, for example deriving a torsion tube 
from a torsion bar by dividing the moment integral into two regions and optimizing over them. [23] 

Finally, a good deal of work at about this level of abstraction uses constraint propagation. 
Gossard and his students explore “variational geometry”, in which systems of equations are tied 
to geometric descriptions of parts. Much of this work has been directed to issues of computational 
efficiency, but see Serrano[24] for a system that allows the designer to use schematics in building 
an equation network for analysis (not compilation) of a mechanical design. Popplestone[25] et al 
have used an algebraic constraint propagator as part of a very large system with similar goals. 
Gross[26]proposes a similar system for architectural design. Fleming[27], propagates the geometric 
tolerances of parts. Steinberg et al[28] have partially integrated top-down refinement (in the sense 
of progressively dividing a design problem into modules) and constraint propagation with a hill¬ 
climbing mechanism. 

These constraint propagation systems, and our earlier work[29, 30], propagate equalities only, or 
else give intervals the limit interpretation and propagate them using only equivalents to the range 
operation. However, see Lozano-Perez et al[31] for a generalization of the domain operation, the 
pre-image, used to formulate robot motion plans under uncertainty. 

5.5 A summary, with contrasts 

We can now summarize our work, emphasizing points of contrast with the “mechanical design” 
programs mentioned above. 
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• We provide an explicit and “compositional” high level language in which designers can define 
new systems and problems. Formal operations on this language automatically transform high- 
level descriptions into detailed descriptions. 

• Our design descriptions explicitly represent sets of artifacts and operating conditions, rather 
than a single or “archetypical” artifact under a single operating condition. 

• We search by progressively narrowing volumes of the artifact space, rather than from point to 
point in that space. 

• We add the domain and sufficient-points operations on intervals to the range constraint- 
propagating operation. 

• We add the operating region interpretation of intervals to the limit interpretation. 

• We divide specification statements into those which are true of all the artifacts represented 
(Assured), those which must be true of the final design (Required), and those which may or 
may not be true but which cannot be strengthened (No-stronger-possible). 

• We divide variables into “causality classes” (parameters vs state-variables). 

We believe these concepts are sufficient to support design compilation over a much of the power 
transmission system domain. (We have not attempted to design servo-systems, or use components 
which are not pre-cataloged.) The design compiler program we have written tests this hypothesis. 

6 Results 

We have tested our design compiler on more than a dozen arrangements of components. The 
data base for these tests includes specifications on such quantities as motor speeds and torques, 
pump pressure ratings, efficiencies, and displaced volumes, etc, as well as the related power trans¬ 
mission equations. Also included are equations for determining such quantities as ball screw critical 
frequency and buckling load. 

There are often multiple solutions satisfying the specifications for a given problem. Also, because 
information is lost in abstracting, a group of alternatives may “hide” some unsatisfactory ones. The 
system therefore interleaves elimination steps with search steps, looking for the optimum solution 
as defined by a user-supplied objective function. 

Fig. 7 shows an example component arrangement. The numbers in the schematic symbols 
indicate the number of line items in the catalogs represented; there are initially 404,352 possible 
combinations. With reasonable user specifications (for example on the speeds at which the loads 
should move and the forces required to move them) and a utility function (say summing the cost 
and weight), the system takes about 10 minutes 1 to find an optimal solution. 

Testing continues; we defer a detailed discussion of the capabilities and limitations of the inference 
system and the search procedure to [2]. We present here conclusions based on example problems 
solved to date. 

• Our language is powerful enough to capture most of the information provided in catalogs for 
a wide range of components. 

• Our inference operations appear to result in only correct eliminations when components are 
appropriately modelled. 

'On a Symbolics 3640 Lisp machine, running our unoptimized research code. 
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Figure 7: A hydraulic example 

• The idea that design descriptions represent sets of artifacts and operating conditions is pow¬ 
erful. We could not have worked through the complexities of the theory without it. 

• Our work is incomplete. For example, the adjustable position of the seat back in a automobile 
is neither a parameter nor a state variable. We are now exploring relationships between 

only 

variables and intervals additional to Limits ([ ] ) and Operating-Regions ( ev ff y ). We are at 
present restricted to invertible algebraic equations and to positive values for variables. We 
have explored geometric issues only very lightly. Our abstraction procedures can be made 
stronger. More subtly, “hard-edged” interval representations such as ours distort the real 
significance of some specifications[32]. 
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